home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 480 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.9 KB
  1. Path: engnews1.Eng.Sun.COM!taumet!clamage
  2. From: "Paul D. DeRocco" <pderocco@ix.netcom.com>
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Conflicting purposes of exception spec
  5. Date: 19 Feb 1996 16:52:15 GMT
  6. Organization: Netcom
  7. Approved: clamage@eng.sun.com (comp.std.c++)
  8. Message-ID: <31284EB5.461@ix.netcom.com>
  9. References: <3125C082.2946@ix.netcom.com> <4g7m55$pof@engnews1.Eng.Sun.COM>
  10. NNTP-Posting-Host: taumet.eng.sun.com
  11. Mime-Version: 1.0
  12. Content-Type: text/plain; charset=us-ascii
  13. Content-Transfer-Encoding: 7bit
  14. X-Nntp-Posting-Host: ix-bst-ma1-09.ix.netcom.com
  15. X-Netcom-Date: Mon Feb 19  2:26:04 AM PST 1996
  16. X-Mailer: Mozilla 2.0b6a (Win95; I)
  17. Content-Length: 1912
  18. Originator: clamage@taumet
  19.  
  20. Steve Clamage wrote:
  21.  
  22. > If sumsq has a throw() clause, the compiler can assume that
  23. > no exceptions will escape from sumsq, and perhaps can avoid adding
  24. > exception-handling code to the calling location. At the call
  25. > site, there are no disadvantages to sumsq's empty exception-spec,
  26. > and there are potential advantages, as you noted in your article.
  27.  
  28. The Borland compiler makes no attempt at optimizition of the caller in 
  29. this case.
  30.  
  31. > If a function has an empty exception-spec, the compiler must in
  32. > general add scaffolding to the function to ensure that any exceptions
  33. > occurring in the function do not escape. In the case of sumsq, the
  34. > compiler may be able to determine that no exception is possible,
  35. > and not generate the extra code. If the extra code is generated,
  36. > on most implementations it does not add to the run time of the
  37. > function.  Typically none of the extra code is executed unless an
  38. > exception actually occurs and would otherwise escape from the 
  39. > function.
  40.  
  41. The Borland compiler makes no attempt to deduce whether it really needs 
  42. this code, and adds it no matter what. It amounts to a couple of calls 
  43. to helper functions which don't amount to that much code, but too much, 
  44. in my view, for simple functions like sumsq (or, say, C string handling 
  45. functions like strlen).
  46.  
  47. It was my experience with the Borland compiler that led me to these 
  48. thoughts. I tried adding throw() to all my diddling little utility 
  49. functions, in the hopes that it would simplify some of the calling code, 
  50. and was surprised to find that it didn't do that, but instead made the 
  51. functions more complicated. I then decided to junk the throw() 
  52. specifiers. Then, however, it occurred to me that with a different 
  53. compiler, junking the throw() specifiers could be the exact wrong thing 
  54. to do. Hence, my desire for throw(void) to be explicitly defined as an 
  55. optimization hint.
  56.  
  57. -- 
  58.  
  59. Ciao,
  60. Paul D. DeRocco
  61.  
  62. [ To submit articles: Try just posting with your newsreader.  If that fails,
  63.               use mailto:std-c++@ncar.ucar.edu
  64.   FAQ:    http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  65.   Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  66.   Comments? mailto:std-c++-request@ncar.ucar.edu
  67. ]
  68.